Stream: Internet Engineering Task Force (IETF) 


RFC: 8667 

Category: Standards Track 

Published: December 2019 

ISSN: 2070-1721 

Authors: 
S. Previdi, Ed. L. Ginsberg, Ed. C. Filsfils A.Bashandy H. Gredler 
Huawei Technologies Cisco Systems, Inc. Cisco Systems, Inc. Arrcus RtBrick Inc. 
B. Decraene 
Orange 


RFC 8667 
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Abstract 


Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by 
encoding paths as sequences of topological sub-paths, called "segments". These segments are 
advertised by the link-state routing protocols (IS-IS and OSPF). 


This document describes the IS-IS extensions that need to be introduced for Segment Routing 
operating on an MPLS data plane. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8667. 


Copyright Notice 


Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
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with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by 
encoding paths as sequences of topological sub-paths, called "segments". These segments are 
advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an 
ECMP-aware shortest path to a prefix (or a node), as per the state of the IGP topology. Adjacency 
segments represent a hop over a specific adjacency between two nodes in the IGP. A prefix 
segment is typically a multi-hop path while an adjacency segment, in most of the cases, is a one- 
hop path. SR's control plane can be applied to both IPv6 and MPLS data planes and does not 
require any additional signaling (other than the regular IGP). For example, when used in MPLS 
networks, SR paths do not require any LDP or RSVP-TE signaling. Still, SR can interoperate in the 
presence of Label Switched Paths (LSPs) established with RSVP or LDP. 


There are additional segment types, e.g., the Binding SID as defined in [RFC8402]. This document 
also defines an advertisement for one type of Binding SID: the Mirror Context segment. 


This document describes the IS-IS extensions that need to be introduced for Segment Routing 
operating on an MPLS data plane. 


The Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are 
described in [RFC7855]. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 
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2. Segment Routing Identifiers 


The Segment Routing architecture [RFC8402] defines different types of Segment Identifiers (SIDs). 
This document defines the IS-IS encodings for the IGP-Prefix Segment, the IGP-Adjacency 
Segment, the IGP-LAN-Adjacency Segment, and the Binding Segment. 


2.1. Prefix Segment Identifier (Prefix-SID) Sub-TLV 
A new IS-IS sub-TLV is defined: the Prefix Segment Identifier (Prefix-SID) sub-TLV. 


The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as defined in [RFC8402]. The 
"Prefix-SID' MUST be unique within a given IGP domain (when the L-Flag is not set). 


A Prefix-SID sub-TLV is associated to a prefix advertised by a node and MAY be present in any of 
the following TLVs: 


TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. 

TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120]. 

TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 

TLV-237 (Multi-topology IPv6 IP Reachability) defined in [RFC5120]. 

The Binding TLV and Multi-Topology Binding TLV are defined in Sections 2.4 and 2.5, 


respectively. 


The Prefix-SID sub-TLV has the following format: 


0 al 2 3 
OL 2535475) 62789 O A E 5405 60 1 3892000122039 74 5067 8399071! 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Flags | Algorithm 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SID/Index/Label (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— +— + 


where: 
Type: 3 
Length: 5 or 6 depending on the size of the SID (described below) 


Flags: — 1-octet field of the following flags: 


9171223 40592677 


where: 
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Re-advertisement Flag. If set, then the prefix to which this Prefix-SID is 
attached has been propagated by the router from either another level (i.e., 
from Level-1 to Level-2 or the opposite) or redistribution (e.g., from 
another protocol). 


Node-SID Flag. If set, then the Prefix-SID refers to the router identified by 
the prefix. Typically, the N-Flag is set on Prefix-SIDs that are attached to a 
router loopback address. The N-Flag is set when the Prefix-SID is a Node- 
SID as described in [RFC8402]. 


No-PHP (No Penultimate Hop-Popping) Flag. If set, then the penultimate 
hop MUST NOT pop the Prefix-SID before delivering the packet to the node 
that advertised the Prefix-SID. 


Explicit NULL Flag. If set, any upstream neighbor of the Prefix-SID 
originator MUST replace the Prefix-SID with a Prefix-SID that has an 
Explicit NULL value (0 for IPv4 and 2 for IPv6) before forwarding the 
packet. 


Value Flag. If set, then the Prefix-SID carries a value (instead of an index). 
By default, the flag is UNSET. 


Local Flag. If set, then the value/index carried by the Prefix-SID has local 
significance. By default, the flag is UNSET. 


Other bits: MUST be zero when originated and ignored when received. 


Algorithm: the router may use various algorithms when calculating reachability to other 
nodes or to prefixes attached to these nodes. Algorithm identifiers are defined in 
Section 3.2. Examples of these algorithms are metric-based Shortest Path First (SPF), 
various sorts of Constrained SPF, etc. The Algorithm field of the Prefix-SID contains the 
identifier of the algorithm the router uses to compute the reachability of the prefix to 
which the Prefix-SID is associated. 


At origination, the Prefix-SID Algorithm field MUST be set to 0 or to any value advertised in 
the SR-Algorithm sub-TLV (see Section 3.2). 


A router receiving a Prefix-SID from a remote node and with an algorithm value that such 
remote node has not advertised in the SR-Algorithm sub-TLV (see Section 3.2) MUST ignore 
the Prefix-SID sub-TLV. 


SID/Index/Label as defined in Section 2.1.1.1. 


When the Prefix-SID is an index (and the V-Flag is not set), the value is used to determine the 
actual label value inside the set of all advertised label ranges of a given router. This allows a 
receiving router to construct the forwarding state to a particular destination router. 


In many use cases, a 'stable transport' address is overloaded as an identifier of a given node. 
Because Prefixes may be re-advertised into other levels, there may be some ambiguity (e.g., 
originating router vs. L1L2 router) for which node a particular IP prefix serves as the identifier. 
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The Prefix-SID sub-TLV contains the necessary flags to disambiguate Prefix-to-node mappings. 
Furthermore, if a given node has several 'stable transport' addresses, there are flags to 
differentiate those among other Prefixes advertised from a given node. 


2.1.1. Flags 


2.1.1.1. V-Flag and L-Flag 
The V-Flag indicates whether the SID/Index/Label field is a value or an index. 


The L-Flag indicates whether the value/index in the SID/Index/Label field has local or global 
significance. 


The following settings for V-Flag and L-Flag are valid: 


The V-Flag and L-Flag are set to0: The SID/Index/Label field is a 4-octet index defining the 
offset in the SID/Label space advertised by this router using the encodings defined in 
Section 3.1. 


The V-Flag and L-Flag are set to 1: The SID/Index/Label field is a 3-octet local label where 
the 20 rightmost bits are used for encoding the label value. 


All other combinations of V-Flag and L-Flag are invalid, and any SID advertisement received with 
an invalid setting for the V-Flag and L-Flag MUST be ignored. 


2.1.1.2. R-Flag and N-Flag 
The R-Flag MUST be set for prefixes that are not local to the router and are advertised because of: 


propagation (Level-1 into Level-2); 
leaking (Level-2 into Level-1); or 
redistribution (e.g., from another protocol). 
In the case where a Level-1-2 router has local interface addresses configured in one level, it may 


also propagate these addresses into the other level. In such case, the Level-1-2 router MUST NOT 
set the R bit. 


The N-Flag is used in order to define a Node-SID. A router MAY set the N-Flag only if all of the 
following conditions are met: 


The prefix to which the Prefix-SID is attached is local to the router (i.e., the prefix is 
configured on one of the local interfaces, e.g., a ‘stable transport’ loopback). 

The prefix to which the Prefix-SID is attached has a Prefix length of either /32 (IPv4) or /128 
(IPv6). 


The router MUST ignore the N-Flag on a received Prefix-SID if the prefix has a Prefix length 
different than /32 (IPv4) or /128 (IPv6). 
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The Prefix Attribute Flags sub-TLV [RFC7794] also defines the N-Flag and R-Flag and with the 
same semantics of the equivalent flags defined in this document. Whenever the Prefix Attribute 
Flags sub-TLV is present for a given prefix, the values of the N-Flag and R-Flag advertised in that 
sub-TLV MUST be used, and the values in a corresponding Prefix-SID sub-TLV (if present) MUST be 
ignored. 


2.1.1.3. E-Flag and P-Flag 
The following behavior is associated with the settings of the E-Flag and P-Flag: 


* If the P-Flag is not set, then any upstream neighbor of the Prefix-SID originator MUST pop the 
Prefix-SID. This is equivalent to the "penultimate hop-popping" mechanism used in the MPLS 
data plane, which improves performance of the ultimate hop. MPLS EXP bits of the Prefix- 
SID are not preserved to the ultimate hop (the Prefix-SID being removed). If the P-Flag is 
unset, the received E-Flag is ignored. 


If the P-Flag is set, then: 


o 


If the E-Flag is not set, then any upstream neighbor of the Prefix-SID originator MUST keep 
the Prefix-SID on top of the stack. This is useful when, e.g., the originator of the Prefix-SID 
must stitch the incoming packet into a continuing MPLS LSP to the final destination. This 
could occur at an inter-area border router (prefix propagation from one area to another) 
or at an interdomain border router (prefix propagation from one domain to another). 

If the E-Flag is set, then any upstream neighbor of the Prefix-SID originator MUST replace 
the Prefix-SID with a Prefix-SID having an Explicit NULL value. This is useful, e.g., when 
the originator of the Prefix-SID is the final destination for the related prefix and the 
originator wishes to receive the packet with the original EXP bits. 


o 


When propagating (from either Level-1 to Level-2 or Level-2 to Level-1) a reachability 
advertisement originated by another IS-IS speaker, the router MUST set the P-Flag and MUST clear 
the E-Flag of the related Prefix-SIDs. 

2.1.2. Prefix-SID Propagation 

The Prefix-SID sub-TLV MUST be included when the associated Prefix Reachability TLV is 
propagated across level boundaries. 


The Level-1-2 router that propagates the Prefix-SID sub-TLV between levels maintains the content 
(flags and SID), except as noted in Sections 2.1.1.2 and 2.1.1.3. 


2.2. Adjacency Segment Identifier 
A new IS-IS sub-TLV is defined: the Adjacency Segment Identifier (Adj-SID) sub-TLV. 


The Adj-SID sub-TLV is an optional sub-TLV carrying the Segment Routing IGP-Adjacency-SID as 
defined in [RFC8402] with flags and fields that may be used, in future extensions of Segment 
Routing, for carrying other types of SIDs. 
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IS-IS adjacencies are advertised using one of the IS Neighbor TLVs below: 


TLV-22 (Extended IS reachability) [RFC5305] 

TLV-222 (MT-ISN) [RFC5120] 

TLV-23 (IS Neighbor Attribute) [RFC5311] 

TLV-223 (MT IS Neighbor Attribute) [RFC5311] 
TLV-141 (inter-AS reachability information) [RFC5316] 


Multiple Adj-SID sub-TLVs MAY be associated with a single IS Neighbor. 


2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 
The following format is defined for the Adj-SID sub-TLV: 


0 


db 2 3 


05102995455 6S 4S) (0) al 2 735455 5 GN TE GEORONST 21730455 5677 S: 9x 10) al 
T—R-—R-—R—R-R-R-R-B-4B-R-BLM BB BMMBMBRM B BBMBM BB BB BB BB 


| Type 


Length | Flags | Weight 


T 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+ 


SID/Label/Index (variable) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


where: 


Type: 
Length: 
Flags: 


Previdi, et al. 


31 


5 or 6 depending on size of the SID 


1-octet field of the following flags: 


where: 


F-Flag: 


B-Flag: 


V-Flag: 


L-Flag: 


omT2S TA 0526/7 
+-+-+-+-+-+-+-+-+ 


|FIBIV|L|S|P] | 
+-+-+-+-+-+-+-+-+ 


Address-Family Flag. If unset, then the Adj-SID is used when forwarding 
IPv4-encapsulated traffic to the neighbor. If set, then the Adj-SID is used 
when forwarding IPv6-encapsulated traffic to the neighbor. 


Backup Flag. If set, the Adj-SID is eligible for protection (e.g., using IP Fast 
Reroute (IPFRR) or MPLS Fast Reroute (MPLS-FRR)) as described in 
[RFC8402]. 


Value Flag. If set, then the Adj-SID carries a value. By default, the flag is 
SEL 


Local Flag. If set, then the value/index carried by the Adj-SID has local 
significance. By default, the flag is SET. 
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S-Flag: Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of 
adjacencies (and therefore MAY be assigned to other adjacencies as well). 


P-Flag: Persistent Flag. When set, the P-Flag indicates that the Adj-SID is 
persistently allocated, i.e., the Adj-SID value remains consistent across 
router restart and/or interface flap. 


Other bits: MUST be zero when originated and ignored when received. 


Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load 
balancing. The use of the weight is defined in [RFC8402]. 

SID/Index/Label as defined in Section 2.1.1.1. 

An SR-capable router MAY allocate an Adj-SID for each of its adjacencies. 

An SR-capable router MAY allocate more than one Adj-SID to an adjacency. 

An SR-capable router MAY allocate the same Adj-SID to different adjacencies. 


When the P-Flag is not set, the Adj-SID MAY be persistent. When the P-Flag is set, the Adj-SID 
MUST be persistent. 


Examples of Adj-SID sub-TLV use are described in [RFC8402]. 
The F-Flag is used in order for the router to advertise the outgoing encapsulation of the 
adjacency the Adj-SID is attached to. 

2.2.2. Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV 

In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the 


Pseudonode LSP (PN LSP) including all neighbors of the DIS. 


When Segment Routing is used, each router in the LAN MAY advertise the Adj-SID of each of its 
neighbors. Since, on LANS, each router only advertises one adjacency to the DIS (and doesn't 
advertise any other adjacency), each router advertises the set of Adj-SIDs (for each of its 
neighbors) inside a newly defined sub-TLV that is a part of the TLV advertising the adjacency to 
the DIS (e.g., TLV-22). 


The following new sub-TLV is defined: LAN Adjacency Segment Identifier (LAN-Adj-SID) 
containing the set of Adj-SIDs the router assigned to each of its LAN neighbors. 


The format of the LAN-Adj-SID sub-TLV is as follows: 
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0 1 2 3 
OAs 27 3°475) 6 7 8930 23,455.67 89 O12) 3 4556 108 95071 
ee eee 
| Type | Length | Flags | Weight 
T—*—4-—4—.—L-4—R-.-4-4-.-R-4-4-4-.-R-.-R--.-R-.4-R--—R---L-.-4-6 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 

| Neighbor System-ID (ID length octets) 

+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 
+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| SID/Label/Index (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 32 
Length: Variable 
Flags: 1-octet field of the following flags: 


9102435425 5569, 
+-+-+-+-+-+-+-+-+ 


|F|B|VILI|SIP] | 
+-+-+-+-+-+-+-+-+ 


where the F-Flag, B-Flag, V-Flag, L-Flag, S-Flag, and P-Flag are defined in Section 
Z2. 


Other bits: | MUST be zero when originated and ignored when received. 


Weight: 1 octet. The value represents the weight of the Adj-SID for the purpose of load 
balancing. The use of the weight is defined in [RFC8402]. 


Neighbor System-ID: IS-IS System-ID of length "ID Length" as defined in [15010589]. 
SID/Index/Label: As defined in Section 2.1.1.1. 

Multiple LAN-Adj-SID sub-TLVs MAY be encoded. 

Note that this sub-TLV MUST NOT appear in TLV 141. 


In case TLV-22, TLV-23, TLV-222, or TLV-223 (reporting the adjacency to the DIS) can't contain the 
whole set of LAN-Adj-SID sub-TLVs, multiple advertisements of the adjacency to the DIS MUST be 
used, and all advertisements MUST have the same metric. 


Each router within the level, by receiving the DIS PN LSP as well as the non-PN LSP of each 
router in the LAN, is capable of reconstructing the LAN topology as well as the set of Adj-SIDs 
each router uses for each of its neighbors. 
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2.3. SID/Label Sub-TLV 
The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs defined in this document: 


SR-Capabilities sub-TLV (Section 3.1) 

SR Local Block sub-TLV (Section 3.3) 

SID/Label Binding TLV (Section 2.4) 
Multi-Topology SID/Label Binding TLV (Section 2.5) 


Note that the codepoint used in all of the above cases is the SID/Label sub-TLV codepoint 
specified in the new "sub-TLVs for TLV 149 and 150" registry created by this document. 


The SID/Label sub-TLV contains a SID or an MPLS label. The SID/Label sub-TLV has the following 
format: 


0 1 2 3 
0NIUT293 420555601 8598010792943 740554 GN 7227 89 9202192035419 556 af oe IO al 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | 
T—*—4-—R—.—R-—R-.L-B-4L-.-R-4-4-4-.-R-.4-4-.-.-R-.-R-.-R--R--4--4-6 
| SID/Label (variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


where: 
Type: 1 
Length: 3or4 
SID/Label: Ifthe length is set to 3, then the 20 rightmost bits represent an MPLS label. If the 


length is set to 4, then the value is a 32-bit index. 


2.4. SID/Label Binding TLV 


The SID/Label Binding TLV MAY be originated by any router in an IS-IS domain. There are 
multiple uses of the SID/Label Binding TLV. 


The SID/Label Binding TLV may be used to advertise prefixes to SID/Label mappings. This 
functionality is called the Segment Routing Mapping Server (SRMS). The behavior of the SRMS is 
defined in [RFC8661]. 


The SID/Label Binding TLV may also be used to advertise a Mirror SID indicating the ability of a 
node to process traffic originally destined to another IGP node. This behavior is defined in 
[RFC8402]. 


The SID/Label Binding TLV has the following format: 
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al 


2 


3 


92 3 4 506 8 9°10) 45 2345) 6 7 S790) 1 253455 6 7 89° 0 1 


to+-4-4-4+-4-4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4-4-4-4 


| Type | Length | Flags | RESERVED | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Range | Prefix Length | Prefix | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Hf Prefix (continued, variable) Hip 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Sub-TLVs (variable) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
where: 

Type: 149 

Length: Variable 

Flags: 1 octet 

RESERVED: 1 octet (SHOULD be transmitted as 0 and MUST be ignored on receipt) 

Range: 2 octets 


Prefix Length: 1 octet 


Prefix: 


0-16 octets 


sub-TLVs, where each sub-TLV consists of a sequence of: 


° 1 octet of sub-TLV type 


° 1 octet of length of the value field of the sub-TLV 


» 0-243 octets of value 


2.4.1. Flags 


Flags: 1-octet field of the following flags: 


912-3 4°56 7 


+-+-+-+-+-+-+-+-+ 
|F|M|S|DJA| | 
+-+-+-+-+-+-+-+-+ 


where: 


F-Flag: 


M-Flag: 


S-Flag: 
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Address-Family Flag. If unset, then the prefix carries an IPv4 prefix. If set, then the 


prefix carries an IPV6 prefix. 


Mirror Context Flag. Set if the advertised SID corresponds to a mirrored context. 


The use of a mirrored context is described in [RFC8402]. 
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If set, the SID/Label Binding TLV SHOULD be flooded across the entire routing 
domain. If the S-Flag is not set, the SID/Label Binding TLV MUST NOT be leaked 
between levels. This bit MUST NOT be altered during the TLV leaking. 


D-Flag: When the SID/Label Binding TLV is leaked from Level-2 to Level-1, the D-Flag MUST 
be set. Otherwise, this flag MUST be clear. SID/Label Binding TLVs with the D-Flag 
set MUST NOT be leaked from Level-1 to Level-2. This is to prevent TLV looping 
across levels. 


A-Flag: Attached Flag. The originator of the SID/Label Binding TLV MAY set the A bit in 
order to signal that the prefixes and SIDs advertised in the SID/Label Binding TLV 
are directly connected to their originators. The mechanisms through which the 
originator of the SID/Label Binding TLV can figure out if a prefix is attached or not 
are outside the scope of this document (e.g., through explicit configuration). If the 
Binding TLV is leaked to other areas/levels, the A-Flag MUST be cleared. 


An implementation may decide not to honor the S-Flag in order to not leak Binding TLVs 
between levels (for policy reasons). 


Other bits: MUST be zero when originated and ignored when received. 


2.4.2. Range 


The 'Range' field provides the ability to specify a range of addresses and their associated Prefix- 
SIDs. This advertisement supports the SRMS functionality. It is essentially a compression scheme 
to distribute a continuous prefix and their continuous, corresponding SID/Label Block. If a single 
SID is advertised, then the Range field MUST be set to one. For range advertisements > 1, the 
Range field MUST be set to the number of addresses that need to be mapped into a Prefix-SID. In 
either case, the prefix is the first address to which a SID is to be assigned. 


2.4.3. Prefix Length, Prefix 


The 'Prefix' represents the Forwarding Equivalence Class at the tail end of the advertised path. 
The 'Prefix' does not need to correspond to a routable prefix of the originating node. 


The 'Prefix Length' field contains the length of the prefix in bits. Only the most significant octets 
of the prefix are encoded (i.e., 1 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to up 
16, 3 octets for prefix length 17 up to 24, 4 octets for prefix length 25 up to 32, ...., and 16 octets for 
prefix length 113 up to 128). 


2.4.4. Mapping Server Prefix-SID 


The Prefix-SID sub-TLV is defined in Section 2.1 and contains the SID/Index/Label value 
associated with the prefix and range. The Prefix-SID sub-TLV MUST be present in the SID/Label 
Binding TLV when the M-Flag is clear. The Prefix-SID sub-TLV MUST NOT be present when the M- 
Flag is set. 
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2.4.4.1. Prefix-SID Flags 


The Prefix-SID Flags are defined in Section 2.1. The Mapping Server MAY advertise a mapping 
with the N-Flag set when the prefix being mapped is known in the link-state topology with a 
mask length of 32 (IPv4) or 128 (IPv6) and when the prefix represents a node. The mechanisms 
through which the operator defines that a prefix represents a node are outside the scope of this 
document (typically it will be through configuration). 


The other flags defined in Section 2.1 are not used by the Mapping Server and MUST be ignored at 
reception. 


2.4.4.2. PHP Behavior when Using Mapping Server Advertisements 


As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible 
to determine PHP behavior solely based on the Mapping Server Advertisement. However, if 
additional information is available, PHP behavior may safely be done. The required information 
consists of: 


* A prefix reachability advertisement for the prefix has been received, which includes the 
Prefix Attribute Flags sub-TLV [RFC7794]. 


* X-Flag and R-Flag are both set to 0 in the Prefix Attribute Flags sub-TLV. 


In the absence of a Prefix Attribute Flags sub-TLV [RFC7794], the A-Flag in the Binding TLV 
indicates that the originator of a prefix reachability advertisement is directly connected to the 
prefix; thus, PHP MUST be done by the neighbors of the router originating the prefix reachability 
advertisement. Note that the A-Flag is only valid in the original area in which the Binding TLV is 
advertised. 


2.4.4.3. Prefix-SID Algorithm 
The Algorithm field contains the identifier of the algorithm associated with the SIDs for the prefix 


(es) in the range. Use of the Algorithm field is described in Section 2.1. 
2.4.5. SID/Label Sub-TLV 
The SID/Label sub-TLV (Type: 1) contains the SID/Label value as defined in Section 2.3. It MUST be 
present in the SID/Label Binding TLV when the M-Flag is set in the Flags field of the parent TLV. 
2.4.6. Example Encodings 
Example 1: If the following IPv4 router addresses (loopback addresses) need to be mapped into 
the corresponding Prefix-SID indexes, then: 

Router-A: 192.0.2.1/32, Prefix-SID: Index 1 

Router-B: 192.0.2.2/32, Prefix-SID: Index 2 

Router-C: 192.0.2.3/32, Prefix-SID: Index 3 

Router-D: 192.0.2.4/32, Prefix-SID: Index 4 
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O al 2 S 
Que dU bRONTEGEXO9EONIN2 315m oNESuONONEIS2 ey WAN 5 ONES 


T—4—4-—4-—-R--.-R--4---R--4---L----4R--R-.-.-R-.-4---6 
| Type | Length [6|0|06/0]|0| | RESERVED | 
T—4—L-—4-—-R--.-R--4--—-R--4L--4R-T-R-4L-.-4R-.--.-.-R--4--.-6 
| Range = 4 | 32 | 192 | 
T—4—L-—4--—R--—.-R-4-4--.-4R--4L--4--4-4--R-.-4R-R-.-R-.-4-.--6 
| 9 | 2 | T |Prefix-SID Type | 
T—4—4-—4--R--.-R--4-----4L--4R---4--4R-Y-R-.-.-R--4---6 
| Sub-TLV Length | Flags | Algorithm | 

T—4—--—4-—4-—R--—.-R-4-4---L--4L--4-T-4-4--4R--R-.-.-R-.-4--.-6 
| 1 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Example 2: If the following IPv4 prefixes need to be mapped into the corresponding Prefix-SID 
indexes, then: 

10.1.1/24, Prefix-SID: Index 51 

10.1.2/24, Prefix-SID: Index 52 

10.1.3/24, Prefix-SID: Index 53 

10.1.4/24, Prefix-SID: Index 54 

10.1.5/24, Prefix-SID: Index 55 

10.1.6/24, Prefix-SID: Index 56 

10.1.7/24, Prefix-SID: Index 57 


(0) i 2 S 

002 S405 POR TEGEOCOUICP? ET SOS UGNOCOIE 229 456g OO: 
T—4—4-—4-—-R--.-R-4-4---T--4--R-T-4-4--4--4R-R--R-.-4---6 
| Type | Length [6|0|0/0]|o| | RESERVED | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Range = 7 | 24 | 10 | 
T—4—L-—4--—4--.-4R-.-4--.-R--4L--4-T--4-.-R---R-.-R-.-4---6 
| 1 | 1 |Prefix-SID Type| Sub-TLV Length | 
+ 
| 
+ 
| 
+ 


T—4—4-—R——L-4—R-4-4-4R--4R-T-4-4L-.-R--R-R-.-R--R------- 

Flags | Algorithm | | 

T—*—4-—4——L-4—R-4-v-4R-4-4R-T-4-4L-.-4R--R---R--R--R-T---- 
SH. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Example 3: If the following IPv6 prefixes need to be mapped into the corresponding Prefix-SID 
indexes, then: 

2001:db8:1/48, Prefix-SID: Index 151 

2001:db8:2/48, Prefix-SID: Index 152 

2001:db8:3/48, Prefix-SID: Index 153 

2001:db8:4/48, Prefix-SID: Index 154 
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9 Al 2 9 
OR 3 7205460 532980080192 803 74 509697: 8999051929374 55967: 859 Ome 
T—4—.-—4--4R--.-4R-4-4---4R--4L--R-T-R-4R--R-.-R-.-.-R--4-.--- 
| Type | Length |1|0[06/0]0| | RESERVED | 
T—4—L-—4-4-4--.-R-4-4-.-.-4-4-4L--R-TL-R-4L--4R-.-R-.-.-R-.-4-.-.-- 
| Range = 4 | 48 | 0x20 | 
to+-4-4-4+-4-4-4-4+-4-4-4-4-4-4-4-4-4-4-4+-4-4-4-4+-4-4-4-4+-4-4-4-4-4 
| 0x01 | OxOd | Oxb8 | 0x00 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| 0x01 |Prefix-SID Type| Sub-TLV Length| Flags | 
T—4—.-—4-4-—R--.-4R--4--.-R-4-4L--4-T-R-4L--R-.-R-.-.-R-.-4-.--- 
| Algorithm | 9 
to+-4-4-4+-4-4-4-4+-4-4-4-4-4-4-4-4-4-4-4+-4-4-4-4+-4-4-4-4+-4-4-4-4-4 
| 151 | 

+-+-+-+-+-+-+-+-+ 


It is not expected that a network operator will be able to keep fully continuous Prefix/SID/Index 
mappings. In order to support noncontinuous mapping ranges, an implementation MAY generate 
several instances of Binding TLVs. 


For example, if a router wants to advertise the following ranges: 
Range 16: {192.0.2.1-15, Index 1-15 } 
Range6: {192.0.2.22-27, Index 22-27 } 
Range 41: {192.0.2.44-84, Index 80-120 } 


a router would need to advertise three instances of the Binding TLV. 


2.5. Multi-Topology SID/Label Binding TLV 


The Multi-Topology SID/Label Binding TLV allows the support of Multi-Topology IS-IS (M-ISIS) as 
defined in [RFC5120]. The Multi-Topology SID/Label Binding TLV has the same format as the SID/ 
Label Binding TLV defined in Section 2.4 with the difference consisting of a Multi-topology 
Identifier (MT ID) as defined here below: 


0) al 2 3 
OTL S34 5EONTESEONONIE2EJCASORONTEGSEOSONIM2 USES oS T S O 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| Type | Length | MT ID | 
T—R-—R-R—R-4-R-R-B- B4B B BMBMBLMB- R4 BBMBM BB B BB 
| Flags | RESERVED | Range | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Prefix Length | Prefix (variable) Hit 
T—R—4-—«R--R--.-R-4-R---4R--4L--4R-TL-R-4L-.-R-.-R-.-.-R--4-.-.-- 
| Sub-TLVs (variable) 
to-+-4-4-4+-4-4-4-4+-4-4-4-4-4-4-4-4-4-4-4+-4-4-4-4+-4-4-4-4+-4-4-4-4-4 

where: 

Type: 150 
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Length: Variable 


MT ID is the Multi-topology Identifier defined as: 


9 1 
01235420558 Tf tek Sh (Ole al ed Gey S 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| RESVD | MT TD | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


RESVD: Reserved bits. MUST be reset on transmission and ignored on receive. 


MTID: A 12-bit field containing the non-zero ID of the topology being announced. The 
TLV MUST be ignored if the ID is zero. This is to ensure the consistent view of the 
standard unicast topology. 


The other fields and sub-TLVs are defined in Section 2.4. 


3. Router Capabilities 


This section defines sub-TLVs that are inserted into the IS-IS Router Capability that is defined in 
[RFC7981]. 


3.1. SR-Capabilities Sub-TLV 


Segment Routing requires each router to advertise its SR data plane capability and the range of 
MPLS label values it uses for Segment Routing in the case where global SIDs are allocated (i.e., 
global indexes). Data plane capabilities and label ranges are advertised using the newly defined 
SR-Capabilities sub-TLV. 


The Router Capability TLV specifies flags that control its advertisement. The SR-Capabilities sub- 
TLV MUST be propagated throughout the level and MUST NOT be advertised across level 
boundaries. Therefore, Router Capability TLV distribution flags are set accordingly, i.e., the S-Flag 
in the Router Capability TLV [RFC7981] MUST be unset. 


The SR-Capabilities sub-TLV has the following format: 


(0) 1 2 3 
ORS A Seon On OOM 2 Se 4 ONO T S O Olle 2a Sa 4 om 6 T Ome Ome 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Flags 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Range | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Jy SID/Label Sub-TLV (variable) // 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Type: 2 
Length: Variable 
Flags: 1 octet of flags. The following are defined: 


919243745596, 
+-+-+-+-+-+-+-+-+ 


|1|V| | 
+-+-+-+-+-+-+-+-+ 


where: 


I-Flag: MPLS IPv4 Flag. If set, then the router is capable of processing SR-MPLS- 
encapsulated IPv4 packets on all interfaces. 


V-Flag: MPLS IPv6 Flag. If set, then the router is capable of processing SR-MPLS- 
encapsulated IPv6 packets on all interfaces. 


One or more Segment Routing Global Block (SRGB) Descriptor entries, each of which have 
the following format: 


Range: 3 octets 


SID/Label sub-TLV: MPLS label as defined in Section 2.3 


The SID/Label sub-TLV contains the first value of the SRGB while the range contains the number 
of SRGB elements. The range value MUST be higher than 0. 


The SR-Capabilities sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT 
advertise more than one SR-Capabilities sub-TLV. A router receiving multiple SR-Capabilities sub- 
TLVs from the same originator SHOULD select the first advertisement in the lowest-numbered 
LSP. 


When multiple SRGB Descriptors are advertised, the entries define an ordered set of ranges on 
which a SID index is to be applied. For this reason, changing the order in which the descriptors 
are advertised will have a disruptive effect on forwarding. 


When a router adds a new SRGB Descriptor to an existing SR-Capabilities sub-TLV, the new 
descriptor SHOULD add the newly configured block at the end of the sub-TLV and SHOULD NOT 
change the order of previously advertised blocks. Changing the order of the advertised 
descriptors will create label churn in the FIB and black hole / misdirect some traffic during the 
IGP convergence. In particular, if a range that is not the last is extended, it's preferable to add a 
new range rather than extending the previously advertised range. 


The originating router MUST ensure the order is unchanged after a graceful restart (using 
checkpointing, non-volatile storage, or any other mechanism). 


The originating router MUST NOT advertise overlapping ranges. 
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When a router receives multiple overlapping ranges, it MUST conform to the procedures defined 


in [RFC8660]. 


Here follows an example of the advertisement of multiple ranges: 


The originating router advertises the following ranges: 


SR-Cap: range: 100, SID value: 100 


SR-Cap: range: 100, SID value: 1000 


SR-Cap: range: 100, SID value: 500 


The receiving routers concatenate the ranges in the received order and build the SRGB as 


follows: 


SRGB = [100, 199] 


[1000, 1099] 


[500, 599] 


The indexes span multiple ranges: 


index 
index 
index 
index 


index 


3.2. SR-Algorithm Sub-TLV 


means 
means 
means 
means 


means 


label 
label 
label 
label 


label 


100 
199 
1000 
1099 


500 


The router may use various algorithms when calculating reachability to other nodes or to 
prefixes attached to these nodes. Examples of these algorithms are metric-based SPF, various 
sorts of Constrained SPF, etc. The SR-Algorithm sub-TLV allows the router to advertise the 
algorithms that the router is currently using. Algorithm values are defined in the "IGP Algorithm 


Type" registry defined in [RFC8665]. The following values have been defined: 


0: SPF algorithm based on link metric. This is the well-known shortest path algorithm as 
computed by the IS-IS Decision Process. Consistent with the deployed practice for link- 
state protocols, algorithm 0 permits any node to overwrite the SPF path with a 


different path based on local policy. 


1: Strict SPF algorithm based on link metric. The algorithm is identical to algorithm 0, but 
algorithm 1 requires that all nodes along the path will honor the SPF routing decision. 
Local policy MUST NOT alter the forwarding decision computed by algorithm 1 at the 


node claiming to support algorithm 1. 
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The Router Capability TLV specifies flags that control its advertisement. The SR-Algorithm MUST 
be propagated throughout the level and MUST NOT be advertised across level boundaries. 
Therefore, Router Capability TLV distribution flags are set accordingly, i.e., the S-Flag MUST be 
unset. 


The SR-Algorithm sub-TLV is optional. It MUST NOT be advertised more than once at a given level. 
A router receiving multiple SR-Algorithm sub-TLVs from the same originator SHOULD select the 
first advertisement in the lowest-numbered LSP. 


When the originating router does not advertise the SR-Algorithm sub-TLV, it implies that 
algorithm 0 is the only algorithm supported by the routers that support the extensions defined in 
this document. 


When the originating router does advertise the SR-Algorithm sub-TLV, then algorithm 0 MUST be 
present while non-zero algorithms MAY be present. 


The SR-Algorithm sub-TLV has the following format: 


9 al 2 3 
Qu 2S om OniianOn0 @ Ome Jari A 5 OUT com Om OMe eS 4 oe Omar Ou m One 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
T—*—4-4—4-R--4--4R-4L-.-R-v-R--.-R-.-4---R-.-R--4--4--.-- 
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n 
T—4—4-4—4-4--4-T-4R-4R-.-4R-.-4R--.-R-.-4---R-.-R--4R--4----Y 
where: 
Type: 19 


Length: Variable 


Algorithm: 1 octet of algorithm 


3.3. SR Local Block Sub-TLV 


The SR Local Block (SRLB) sub-TLV contains the range of labels the node has reserved for Local 
SIDs. Local SIDs are used, e.g., for Adj-SIDs, and may also be allocated by components other than 
the IS-IS protocol. As an example, an application or a controller may instruct the router to 
allocate a specific Local SID. Therefore, in order for such applications or controllers to know 
what Local SIDs are available in the router, it is required that the router advertises its SRLB. 


The SRLB sub-TLV is used for this purpose and has following format: 
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(0) 1 2 3 
95152453 5455 6 8094900105203 405560710859 00171020324 055677 8295081 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Flags 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Range | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
// SID/Label Sub-TLV (variable) 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 22 
Length: Variable 


Flags: 1 octet of flags. None are defined at this stage. 
One or more SRLB Descriptor entries, each of which have the following format: 


Range: 3 octets 


SID/Label sub-TLV: MPLS label as defined in Section 2.3 


The SID/Label sub-TLV contains the first value of the SRLB while the range contains the number 
of SRLB elements. The range value MUST be higher than 0. 


The SRLB sub-TLV MAY be advertised in an LSP of any number, but a router MUST NOT advertise 
more than one SRLB sub-TLV. A router receiving multiple SRLB sub-TLVs, from the same 
originator, SHOULD select the first advertisement in the lowest-numbered LSP. 


The originating router MUST NOT advertise overlapping ranges. 


When a router receives multiple overlapping ranges, it MUST conform to the procedures defined 
in [RFC8660]. 


It is important to note that each time a SID from the SRLB is allocated, it should also be reported 
to all components (e.g., controller or applications) in order for these components to have an up- 
to-date view of the current SRLB allocation and to avoid collision between allocation 
instructions. 


Within the context of IS-IS, the reporting of Local SIDs is done through IS-IS sub-TLVs such as the 
Adj-SID. However, the reporting of allocated Local SIDs may also be done through other means 
and protocols that are outside the scope of this document. 


A router advertising the SRLB sub-TLV may also have other label ranges, outside the SRLB, for its 
local allocation purposes that are NOT advertised in the SRLB. For example, it is possible that an 
Adj-SID is allocated using a local label not part of the SRLB. 
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3.4. SRMS Preference Sub-TLV 


The SRMS Preference sub-TLV is used in order to associate a preference with SRMS 
advertisements from a particular source. 


The SRMS Preference sub-TLV has the following format: 


9 1 2 3 
OA Sh 4b sy a Tf e S a A AS ey S S al sh S (5) zfs} 2) (0) al 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Preference | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 24 
Length: 1 
Preference: 1 octet and unsigned 8-bit SRMS preference. 


The SRMS Preference sub-TLV MAY be advertised in an LSP of any number, but a router MUST 
NOT advertise more than one SRMS Preference sub-TLV. A router receiving multiple SRMS 
Preference sub-TLVs, from the same originator, SHOULD select the first advertisement in the 
lowest-numbered LSP. 


The use of the SRMS preference during the SID selection process is described in [RFC8661]. 


4. IANA Considerations 
Per this document, IANA has allocated the following TLVs and sub-TLVs. 


4.1. Sub-TLVs for Types 22, 23, 25, 141, 222, and 223 


This document makes the following registrations in the "Sub-TLVs for TLV 22, 23, 25, 141, 222, 
and 223" registry. 


Type Description 22 23 25 141 222 223 
3l Adjacency Segment Identifier y y n y y y 
32 LAN Adjacency Segment Identifier y y n y y y 


Table 1 


4.2. Sub-TLVs for Types 135, 235, 236, and 237 


This document makes the following registrations in the "Sub-TLVs for TLV 135, 235, 236, and 237" 
registry. 
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Type Description 135 235 236 237 
3 Prefix Segment Identifier y y y y 


Table 2 


4.3. Sub-TLVs for Type 242 
This document makes the following registrations in the "Sub-TLVs for TLV 242" registry. 
Type Description 
2 Segment Routing Capability 
19 Segment Routing Algorithm 
22 Segment Routing Local Block (SRLB) 
24 Segment Routing Mapping Server Preference (SRMS Preference) 


Table 3 


4.4. New TLV Codepoint and Sub-TLV Registry 


This document registers the following TLV: 


Value Name IIH LSP SNP Purge 
149 Segment Identifier / Label Binding n y n n 
150 Multi-Topology Segment Identifier / Label Binding n y n n 

Table 4 


This document creates the following sub-TLV Registry: 


Name: Sub-TLVs for TLVs 149 and 150 


Registration Procedure: Expert Review [RFC8126] 
Type Description 
0 Reserved 
1 SID/Label 
2 Unassigned 


3 Prefix Segment Identifier 
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Type Description 


4-255 Unassigned 
Table 5 


5. Security Considerations 


With the use of the extensions defined in this document, IS-IS carries information that will be 
used to program the MPLS data plane [RFC3031]. In general, the same type of attacks that can be 
carried out on the IP/IPv6 control plane can be carried out on the MPLS control plane, resulting 
in traffic being misrouted in the respective data planes. However, the latter may be more difficult 
to detect and isolate. 


Existing security extensions as described in [RFC5304] and [RFC5310] apply to these Segment 
Routing extensions. 
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